home *** CD-ROM | disk | FTP | other *** search
/ Amiga Developer CD v2.1 / Amiga Developer CD v2.1.iso / DevInfo / DeviceDevelopment / NSD-README < prev    next >
Text File  |  1997-05-15  |  4KB  |  105 lines
  1.  
  2.     $Id: NSD-README 1.5 1997/05/15 18:08:49 heinz Exp $
  3.  
  4.  
  5. What is this about?
  6. ===================
  7.  
  8. Up to and including OS 3.1 (V40), custom device commands usually
  9. started at CMD_NONSTD. Each developer added commands for custom
  10. device features freely. This lead to messy and incompatible
  11. devices and strange compatibility tricks to identify device
  12. capabilities.
  13.  
  14. The goal of this document is to provide for a clean way to identify
  15. device types and capabilities, and, within this framework, to point
  16. out rules, strategies, and ideas to make device usage as safe as
  17. possible without introducing major overhead.
  18.  
  19.  
  20. Terminology
  21. ===========
  22.  
  23. "RKM" means, "Rom Kernel Manuals", the official OS documentation as
  24. published by Addison Wesley. Typically the third Edition,
  25. describing >=V36 is referred to. With "device" an Exec device is
  26. referred to as documented for the context of Exec in the RKM
  27. Libraries 3rd edition, chapter 19 "EXEC DEVICE I/O", page 445:
  28.  
  29.     An Amiga device is a software module that accepts commands and
  30.     data and performs I/O operations based on the commands it
  31.     receives.
  32.  
  33. Underlying hardware is always mentioned if needed, but not referred
  34. to as "device" to be consistent with RKM terminology in that field.
  35. Commands in the reserved ranges are called "new style". A device
  36. that supports new style commands correctly as described in this
  37. document is called a "new style device". The abbreviation used to
  38. easily refer to this standard or to devices adhering to this
  39. standard is called "NSD" for "N"ew "S"tyle "D"evices. Other than
  40. that, the use of "standardese" has been avoided if possible.
  41. Comments on any unclear statements and on errors are very welcome.
  42. There should not be any ambigous statements in this document.
  43.  
  44.  
  45. Sub-Documents
  46. =============
  47.  
  48. While the basic NSD specification itself is very small and easy to
  49. implement, the discussion about the issues involved got more and
  50. more complex over time. For ease of use, the complete NSD
  51. documentation has been split up into sub documents that concentrate
  52. on specific issues. The sub documents shall not be regarded
  53. in isolation. They belong together and shall be used together. The
  54. whole set of sub documents make up the NSD specification:
  55.  
  56.     - NewStyleCommands          The revision number of NSD
  57.     - NSD-README                This document
  58.     - NSD-CommandSpecs          The basic NSD specification
  59.     - NSD-DeviceSpecifics       Device type specific NSD issues
  60.     - NSD-Thoughts              Thoughts and Consequences
  61.     - NSD-Future                The future of NSD
  62.     - NSD-History               The history of NSD
  63.  
  64.  
  65. NSD Conformance
  66. ===============
  67.  
  68. Nothing is ever perfect and the better is always the enemy of the
  69. good. So NSD has evolved and will continue to evolve as needs
  70. change and expand in the future. The RCS Id at the top of the sub
  71. document "NewStyleCommands" is used as revision specifier and
  72. identifies the NSD revision for historic reasons. To avoid
  73. confusion about the terms version/revision, let us use these terms
  74. interchangably here to identify a certain issued NSD specification
  75. or a part thereof.
  76.  
  77. The RCS Id's at the top of the sub documents shall be referred to
  78. as additional check to avoid confusing sub documents belonging to
  79. different revisions of NSD.
  80.  
  81. The list of revisions may not be contigous, as internal, non
  82. published revisions may exists which are of no consequence to users
  83. or to implementers. Only the revisions listed as public in
  84. NSD-History, and of course this revision exist for public
  85. consumption. On request, an archive containing all revisions may be
  86. obtained.
  87.  
  88. It is strongly suggested that an NSD conforming device lists the
  89. revision of the standard it conforms to in its documentation. NSD
  90. is designed to make device usage easy and as safe as possible. As
  91. this standard is revised, new technique for getting closer to this
  92. goal may be found and worked in, while still keeping
  93. implementations adhering to previous revisions valid and usable.
  94.  
  95. NSD relies on your support and ideas, so if you have comments or
  96. gripes, please mail them in to <bugs@amiga.de> and <heinz@amiga.de>
  97. early on in an orderly fashion. Unreported problems that are not
  98. found here obviously cannot be fixed and we all want things to get
  99. better, don't we?
  100.  
  101. Heinz Wrobel
  102. <heinz@amiga.de>
  103.  
  104. *** EOT ***
  105.